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(57) Abstract: Systems (10) and methods for. inter alia, allowing a remote user(14) to access content, such as data or an executable 
program, on demand from a remoter server. When accessed the content can be delived on demand to the user's remote workstation 
(14) for use by the user. As network resources may vary, the systems described herein further include systans tfiat will monitor 
netwoik resources, and other factore, versus the transfer demands for the content requested by the usen The systems may dien 
determine a schedule, or load map (24). for transferring blocks of the coritentin a way that efiBdendy employs the available resources, 
and in a way that provides the user with a user^cxperience that is similar, or substantially similar, to the user-«tperience that the oser 
would have if the content were stored locally on the user's workstation. 
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SYSliMS AND BffiTHO 

OVER A COMPUTER NEt^ 

technical Field 

This inyention relate to methods and systems for delivering content over a 
computer network, including delivering executable and data content that may be 
executed by a remote user in reial time. 
Elackgrouiid Art 

Today, interconnectivity over data networks continues to ex^ Most 
companies today have an internal networic, many of which provide high ^peed data 
delivety to terminals on the network. Additionally, the Internet provides 
mterconnectivity between networks, and terimnals that located across the globe. 

With fte idterconnectivity provided by die Int^et and othia: networks, 
systems have been proposed that wdidd alldWuseis to license, on a per use or per 
hour basis, access to a software title such as Microsoft Pow^ 
docketing software package. In these systems^ oioce the user has been granted access 
to tiie title, tixe user can execute the tide and employ the software as rieeded. 
Typically, the plication service ptovideis have employed a telnet type architiscture 
that has directed the iiser to employ th6 Ul^ wbrkstation as a t^minal, while 
comptdng takes place on a remote p]X)cess6jr that has execution access to the selected 
tide. Alternatively, systons have emjiloyed ah ^S kind of architecture tiiat joins a 
remote file system into the file 

p&ersiy^^ 

programs that have a di^butaible cotiDLponeat arcWtecture, These tities, commonly 
. writt^l in Java/may be downloaded piece nieal to the remote user, for execution by 
that on the user's loc£d tenii^ 

Althougji such component systecas can woi^k weU, they requk^ 
applications familiar to the user be re-written into a distributable architecture fliat 
allows for easy download ov<er the Interiet Moreover, systems based on telnet 
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tedmblogies or on NFS teclmolo^es create pro^ 

resources of tibe remote machine and of sec^ 

Disclosare of Inyeiiiioil 

The systems and methodbs of the invention inclu^ systems for 

5 allowing a remote user to acc^s content, such as data or an executable program, on 

demand from a remote server for local execution. When accused fhe content can be 

delivered on deiotiand to the user's remote wprkste^on for use by the user, providing. 

the user \vith an experience comparable to the user experience provi^ 

accessing the content locally.: As network resourbes may vary, die system 
1 0 herein further include systems that will moioitor network resbttrces, and other &ctors, 

versus the transfer demands for the concentre^ The systems nmy 

then determine a sdiedule and method, or load map, for transferring blocks of the 
^content in a way that efficienily mploys the available resources, and in a way that ^ 

provides the user with a user-^peri^ce 1^ 
IS user- e;q)erience that the user would have if the content were stored locally on the 

user's workstaitidiL 

In one example^stem, a user at a r^bte v^brkstationi may request access to 
(x>ntejiVsuch as an ekeottable p^ In ife^iiseto this itqties^ 
transfers blocks of content to the user, ^hoie each blbck contains eitber data, content 
20 or executable code thkt the reinbtewoi^^ execute the application 

locaUy / The systeik ti^y c<^^ 

executable program as the appUcationreiji^^ OptibnaUy, the systems described 
hebin miay alsb erriploy pr^ 
; ; Iheresoiircetbiis^^ 
25 * More specifically, the sysfems amd methods described herein include a profiler 

process that analyzes the content access pattern, which can include the disk acceiss or 
. . memory access pattern of an executing title and generates a load m^. This process 
. . cm collect iiifdrmation about how the title is accessed firom stoirage as the user 
employs the title. Different user sbeninbs and choibes<^ 
) 30 of stomge access inay be generated. 
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To Ibis md, the profflCT noay obsM^ 
executable content and/or data. During analysis of the content, lie file access pattern 
of the executable content may be observed. The profile may Ifaen create a load m^ 
that is repiesentetive of the disk access or other file or memoiy access that are made 
5 asausersdectsamongthediffeaientoiiltid^ 

TliesystenM described herdn may also Themi^r^er 
may be a computer process that interprets 

creates one or more cache preload requ^. The cache preload requests may be 
representative of requests from the cUent to the reino 
10 componmtsofthe executable title. 

In one embodiment, a cache manager is provided wherein the cache manager 
communicates with the riiap reader and responds to, toer rf^^^ 
the map reader. 

Thus the systemis desoibed herein include scheduling processes that more 
15 eflBciently use networic resources to facilitate this leal-tinie execution of the program. 

• More specifically, the systraiis and methods desaibed herein include a metiidd 
of transmitting data over a network, to st^ 

locatioiL The mediods may comprise detenniniiig a measure of available throughput 
foir transmitting data over the network. The method, in certain practices, butnot all, 
20 may iiiclude, identifying infoiinatioil to be tra^^ ' , 

generating a forward-looking load inap of informiation for a given execution state of 
the program, and based on the load rnap and the execM^ 
ian^ 

throughput and foir maintaining consistent executioii of the program. In these 
25 methods, the information compriseis at least one of data or an executable file. The 

infonnation may be transniitted firbm a s 

The act of identifying information may include selecting information based on 

the available throughput and the execiitidri state of the program at a time of 

selection. Mormationmaybep;^kaged, drWaiss6^^ 
30 more suited to one tfiroughput than another, or that are associated with a fee structure 
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that provides one level of service versus anotha. Additionally aiid optionally, the 
melliods may furflier include tiie acts of tiie client requ^tinig information to be 
trananitted, the clieiit selecting a subset of the information based on the available 
tiiroughput at a time of selection, and tiie client selectirig, for transmission fix)m the 
server to the client, information fiom flie subset of the information. In certain oflier 
practices, the client requestmg information to be transmitted, and if the request is 
appro vedi receivkg a key ad^ted to access the info^^ 
server to the cUcnt Additionally, the metiibds may include tnetfaods whCTem the 
forward-iookmg load inap is generated based an accws pattern for the transmitted 
mfoimation.: TTie access pattern may include the didc access pattern, where the tifle is 
run under dijSerent scenarios or conditions, and the disk access is monitored under 
these conditioins. From tiiis activity, a load map that maps out a sequence for 
retrieving data blocks may be generated 

• The systeins described herein may inchide a system for transmitting structured 
information over a network having an identified available thrbughput, comprising a 
server |)fovidiiig the information, a client receiving liie iirforination fi:bm the server, a 
profile monitoring transmissioja of the iofprination fix)m the sdrver and generating at 
least one load map based on ah analysis of an information access pattern at tiie server, 
a map leader, based on the at least oiie load map, for interpreting information 
contained within a load map and for generating time valued requests to the server 
based on available throughput and informational requirements, arid a cache manager 
ibat merges the information to organize the structured information. The cache 
ma^ information associated 

with pre-load operation and may selert for m^arging a block of the irifonriation firom 
the stoi^e ineiaiis, if the block is avail^le, and requests a block from tiie server, if the 
block is liot yet available. The system rhay alsb iiiclude aplayer which arr^geis for 
the execution of the structured information. 

Additionally, the invention m^y provide methods for providing multiple - 
levels of si5)port for executiiig over a computer network a prograrn having blocks of 
executable code, comprising providing, for a plurality of network performance levels, 

-4- 
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a pluraUty of load ni^s associated wlh 

levels and having a list of sections of executable code of the program ordered 
according to the e3q)ected priority of access of the executable code by the program, 
detexnming a network perferma^ 
5 selecting a load nuq? as a ftmctioh of the network performance level available, and 
allowing the cUent to request sectioiu; of 1^ 
map iselected. QptioiMy, the meflKHl may include p^^ 
generate the plurality of loiad maps^ to this end processing the program includes 
deteiinuiing for a req)ective network jfeifoionance level a preload list repres^tative 
10 of aseries of sections of executable code that are to be transmitted over the to 
prior to execution of the i^graixL 

Processing the program includes monitoring execution of the program to 
detmiiine a sequence of block fetches for moving sections of executable code mto 
computer menaory and cfche during pmgraui (jeneratmg an ordered list 

15 includes oMeriiig delist to px)^^ 

Sections of raeculable cd^ Generating the ordered 

fist to schedule trananission of dcecutable code over Ihenetwork during a period of 
low network activity dxuiig program execute 

Hie method inay determine a network peiformaxice level by launching a 
2b player program at the client capiable of exchanging iofonnation vrith a remote server 
for detennining the available network bandwidth, including launching a player 
program at the client capable of exchanging information with a remote server for 
detettnaning network latency. 

OptioMly, detenniirihg a network peiforinance level includes determining 
25 cache memory available at the client, and selebting a load map mcludes comparing a 
network performance level to a threshold level and preceding to selecting of a load 
m^ as a function of the comparison. 

. O&er mefliods provided herein include a method for providing multiple levels 
of support for executmg over a computer network a program havmg blocks of 
30 executable code, comprismg providing a jBle qrstem inanagementproc^^ 
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moiutcring ffle access operationis of a compti^ 

^plication memoiy space, exectitihg fiie progi^ employing the fil^^ s^tem 
management process. yMe the program is being executed, for Hetemn wing a 
sequence and a timing pattern with which blocks of execntabte code are loaded into ; 
the application m^oiy space, and processing the siequence and timing pattern to 
generate a load m^ rejpresentative of a sequence and timing pattern for transmitting 
blocks of executable code over the network. 

As discussed above, generating a load map mcludes {Processing &e sequence 
and tiinuig pattern to identify periods during program execiiction available for 
traiismitting additional blocks of executable code. This may include determining 
probabilistically the additional bloclcs of executable code to deliver over the network, 
as well as processing the sequence and timing pattern vAnlo coliecting information 
represeiitative of blocks of executable code requested from a reinote site and adjusting 
the load map as a function of the collected infonnatioiL Optionally, the method may 
add trigger controls within the generated load map for controlling post-load execution 
on a client based on programs file accesses. 

Other objects of the mvention will, m part, be obvious, and, in part, be shown 
from the following description of the systems and methods shown herein. 
BriefDescription of Drawings 

Figure 1 depicts schematically the structure of one embodiment of a system 
according to the invention; 

. Bigure 2 depicts on example of a Ix»ad 

: . Figure 3 dqpicts graphically th^ dowhlpad deinahd for a titie veisus tiihe. 
Best Mode for Garir^^ 

To provide an overall understanding of the invention, certain illustrative , 
embodiments will now be described. However, it will be xmderstood by one of 
ordinary skill in the art that the systenis and metiibds described herein may be adapited 
and inodified for other suitable applicaitions and that such other additions and 
mbdifications will not depart from the sdope herebf. 
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pbe systems and methods described herein 
content over a data network, and more particularly include systems and methods for 
delivering executable content dyer a data lietwodc, in a maimer that allows a user at a 
remote site to acbess tiie cont^t on demand to have a user experience that is 
5 comparable to the user experience that would be achieved if the content were being 
accessed locally 

Among the features of the invention is the ability to allow a holder of an 
executable title to securely deploy that title for use by users at remote client systems, 
and to pn)vide that user with an acceptable u^^ To this end, and as will 

10 be explained in greater detail herein after, the systems and methods described herein 
include systems and methods that analyze the throughput available for deUvering data 
between the client and flie server. Based bnthis determined throughput, the systems 
select a deUvery schedule and method for traiisfeiT^ Moreover, . 

the systems monitor the client's use of the content to determine what other content 

15. should be preloaded or cachied on the client system, so that the user's access to the 
content is comparable to the access the user would have if the content was stored 
locally. Ekamplesofsuch systems include cUent/server systems that aUow users a^ 
remote client system to access an executable title stored at a remote location and to 
rim that Me locally on the client system by retrieving on demand portions of the 

20 executable content from the remote server. Thes systems and methods may further 
include a mechanism for determining the network characteristics and throu^ut 
available for transmittmg data between the ^erm^ Upon determining . 

the meaisure of available network characteristics and throughput, the systems and. 
methods described herein employ the determine available network characteristics 

25 and throu^put to select a load map file suitable for tise with a network having the 
identified characteristics and available throughput. The load map file may, in one 
embodiment be a data file associated with the content, or title, that the user at the 
remote client desires to access from the server and Execute locally at the cli^t To 
this end, the load map file may be a data file associated with and repress 

30 title that has been formatted into a paclrag;e that naakes the executable code within the 
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title more easy to segment and to deliver in sections across the data network and to the 
remote! client 

Additionally, the load map may include pre<^ The 
predictive loadiiiig inibmi^ 
5 map reader to fetch segments of the|1itiefit)m To this end, the load map 

may include a method and ah ordeied list of d^^ 

considering the progress of tepartibular title After the title is launched, tiie 

cUmt is to fetch blockis oil this oniCTed list per the 

vdien-the network conditions permit Optionally, the load map may also include 
10 mformation m a tree structure that is representative of a list of a set of blocks, each set 

being associated with an additional set of blocks. If the cUent detects that the blocks 

in the fiu:st order set are being fetched by the titlCj then the blo^ 

set are to be loaded. This provides for probabilistic loadmg. In either case, the load- 

rnap data fUe may incliKiei Mormation a^^^^ 
15 blocks of executable c«de fix)iii the servCTt This probabilistic loadmg, in 

cdmbiiiatioh with the use ot load miaps, can provide flie lisef with a user experience 

thai is comparable to the usCT experiience^ 

stored locally. 

For purposes of iUustratioh, tiie systems aad 
20 described, ia part, with reference to certam iU These 
embodiments wiU largely encompass examp 
allowing a user at a remote cUeht to access ^d exect^^ 

■ \ 

25 ^es of data content 

that the isystenls and m^ 

appUcations desdibed below ^d thM 
. ' <Bhcornpass bfhier appH^^ 

content over a network, web browsing, videb cidiiferencibg and any o^er application 
30 ^ereitwiUbebehefiddtocoordii^ 



-8- 



wo 02/23363 



PGTAJSOl/28452 



expected deitsm^ 
to another site. 

One embodiment of a system according to the invention is dq)icted in Figure 
i. Spiecifically, Figure 1 depicts a systen 10 that employs a client/iservCT architecture - . 
5 toaUowauseronaremotecliOTttoexecutelo^ 
remote server. SpedficaUy, Figure 1 depicts a system 

that optionally may comprise mliltiple servers (S2, 64, 68,1 8 arid 20. and a client 14. 
The stnicture of the cUent 12 aiui the setver 14 includ^^^^ 
in the above identified US patent applicadotis and PCT applications: 60/23 1,992- 
10 entitied Systems and Methods for Delivering Content Ova: a Computer Network, 
filed 1 1 September 2000 and laiming Joe D. Cro 

09/31.0,294; 09/311,923; 09/310,229; 09/439,906; and PCr/US99/27113, which are 

coinmonly assigned, co-pending applicatioiis. For pui^ 

description describes the structure aM^ 
-15 including the operation and structut^ of certam elements of the server 14 and client 12 . 

which were also described with refer^ncfe to the sy^ methods showii in the 

co-petoding appUcations id«itified above. HbWev 

avoid redundancy, the above identified applications have heeii incorpora^ 

reference to provide fiirther understanding of these certain elanents and the 
20 alternative embodiments, piiu:tices and useis of ^ 

The nitistrated Server 

The depicted server 12 includes a server 
(>«m6tecon^^ ^^^^ : ! ^^^^^ 

of tiiieloadmap§ 24 a,bandcrespe(CtiV^ iidaii 
25 optional running title 30. : ' -.'y'y- ■.:■['•'.: • > 

•The server fix)ht end 16 includes a web 
and a conditional access server 68. The server fibiitCT^ 
: a ti^action with the server 12 to purchase access to a titie the ^ 

The server front end 16ismcorlmumcation With the dispa^ The dispatcher 
3d 18 iUustr^ in Figure 1 discovers local RArtser^re^^ 

' • -9- - .. . 
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and bandwidth delivery, and provides this infoiimatidn iq)on request optionally to fibe 
conditional access server 16 and optionally tbie Player 38 of the client 14. There will 
typically be only one instance of the Dispatcher service runmng per bank of RAFT 
servers, although the design should allow for fail-6v^ as well. 

The Random Access File Trmsfer CRAFl) se^ 
content server designed specifically for laternet-bascid content distribution. The 
RAFT server 20 may also be deigned to enable proxy or cache servers on the 
hetwodc. The RAFT can ©iable dynamic bandwidth restrictions and employ other 
niethods to prevent network cbdgestiorL More ^)ecificaUy, the RAFT server 20 is 
capable of serving content to the client 14 . In particular, the client 14, after having 
negotiated with the store firont 16 to purchase access to a title, contacts the RAFT 
server 20 to gain access to that title. The RAFT server 20 can verify that the client 14 
has purchased access to a particular title 22, and can provide the client 14 with iaccess 
to that title. To tids end, the RAFT server 20 can process arequest &om the client 14 
that includes a protocol version, the path name for the title and an access token. The 
protocol version is a 32-bit value used to verify that the client and server are protocol 
•compatible. To validate access, the RAFT server 20 verifies the token is valid. In 
those applications where the user purchased a lirnited amount of access to the title, the 
RAFT ^lerver 20 can monitor the parameters of the users access requests to make sure 
they stay within prescribed limits. For example, the user may have purchased a 
limited amount of access tinie, or access to only cextain portions of the title, or some 
other type of limited access. TTie RAFT server can check the token's parameters, 
such as its start and expimtioh times dxuing the op^n. If the OPEN is 
stici^ssfiil, the RAFT server returns a RAFT file h^ and a uniqiie ID for the briq 
associated with the title. Typically, the RAIT eventually expire, ^d 

tiie RAFT server 20 will ho lonjger grant access to the title 22. 

The RAFT server 20 may be implemented ias an appUc^ 
P0SIX.1 (lEEEStd 1003.1, 1998) coihpatible platform, such as the Sun Solaris® 
dpemtijig^stem cdmmerciaily available fi:om Suh NCciosystdns, Palo Alto, CK or 
the Lmux operatiiig systeim comimercia^^ 

-10- 
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RAFT server may be implen^^ 

Managoneat Protocol (SNMP) master agent executing on top of lie operating system. 
A commerdal p3X)duct suitable for is the 

Emanate prbdiict coinmerciany avmlable from SNMP Research, Inc. The master 
5 agent conmiimicates with the netwoA^ published application program interfeces 
m acconlance >;vith the SNMP stas^^ 

the server 12 fijrfher includes a plurality of titles 22 as shown in Fig. 1 . In the 
embodiment of Fig J, a tide 22 is forniatted into an e^ 
fee title's files in a compressed and eiiciypt!^ 
1 0 software used in the system of Figure 1 is packaged in briqs 22. The briq 22 contains 
the executables, siq)port software, and data files, arranged in the appropriate directory 
structure. Additionally, flie briq may contain meta data tiiat that supports an mstall 
• abstraction, security, system requirements, and otl^^ 

the title to execute locally. At the 1^ 12, 
15 data is fetched m discrete units, rcf^^ 

blcdk sdze may be fixed it sbnie pbw of 2, siiichi as 32768 b^ When the tifle ' 
runnirig on the cUent 14 1^ 

mform]aition, >diich iire to be satisfied frpm the associated briq 22, these requests are 
translate to some extent of bytes in tbe associated briq 22. The client 14 thai fetches 
20 tiie Blodk or Blocks in which this extent of bytes is stored. He briq 22 is a portable, 
self-contdned file system, containing files and meta-data to be employed to nm 'a 
paiticvto tWe, Briqs 22 are stored on the file server 12, or a storag 

or t(S #d(ar^ 14. 
• Figure 1 shows that the server 12 mcludes a plurality of briqs 22. In tiie 
25 embbdinient of F'igure 1, each of the depicted Title laiqs 22 is associated with a 
- sei)arate title or titles. For each fitie briq 22 tiiere are a plural 
The different load maps 24 for each respective titie briq 22, provide different loadii^ 
profiles or loading schedules and metiiods for tiie respective title briq22, wh^ein the 
difference in loadmg profiles or load schedule and methods arises fiom the differrace 
30 m network characteristics and throughput that can arise when users request access to a 

-11- - ' ■ 
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particular title. IThjs, for exaioiple, diiring the course of a day, two separate users may 
Negotiate access to the same title, to provideaquaHty user e3q)eiiehce, ffie system 10 
may detensmuae the network charadims^^ 

delivering the blocks to the user. In this example, the fiist user may have a high speed 
5 cable access that is providing about 1Mbit th-ougtqiut and tniniTr iiffl l^tfingy In 

contrast die second user may have a DSL connection that is presently biixdehed and is 
providing about 300 Kbit throughput with high latency. Thus the ability to provide 
the user with timely access to the data neis^ed to run the title on the user's local 
machine differs between the two tfiers. Thus, in the case of the first user, the server 

10 has 1Mbit of througl^ut available and loW latency. Throughput may be understood as 
the rate at which data may be transferred between die Raft server 20 and the player 
38. The throughput is effected by the network resources, including bandwidth, 
latency, QoS and other fectors. Thus, the server 12 can employ a schedule and method 
of access that downloads the blocks necess^ to begin the title run, and can service 

15 the title's request for more blocks on demand on a network channel that provides 
l^^it of throughput In contrast, the server 12 has only 300Kbit of througjiput to 
service the second user. Thus, the client may need to preload a greater number of 
blocks into cache prior to the title starting in oidcr to preserve the quality of play. In 
addition a second access mefliod may be deploy6^^ 

20 conditions to request further blocks fiom the server, riot on demand, after the title is 
running on the cUent predicting fiiture needs of ^ The 
point ' is that with high throughput between the server arid the client less data needs to 
be prdoaded into cache before the title 13 la^ 

reidtuneasthet^ : ' ' - ' /.v 

25 To address the possible disparity arid changing network cbnditioiis of 

throughput available between the server 12 arid diflFetent users, the systerii 10 of 
Figure 1 provides a plurality of load maps 24, v^ctc the load maps 24 provide a 
, . delivery schedule and access fnethods that is adapted to support delivery of tide 
content for the associated network Char^enstics and fhrouglpiit in a mariner that 

■ ■ ^ -^12- ' . 
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aclueves a user esqperimce for the 11^^ 
e3q>^eaoe tte user would have if the tMe w 

To this end, the load ings 24 contahi itifoimation that the load map readers 
52 on Ihe client 14 can use to request blocks fibm the server 12 with a schedule and 
5 melhod that should niake blocks available from cache te^ 

needs thean, thus providing a user experience that is identical or similar to the user 
experience the user would have if the title vvere stor^ locally. To this end, load 
maps, like load m^ 24, work in conjunction with the local cache. If a request is 
made for data and it is not in th(5ca<Ae it goes directly to RA^ Thus,asthe 

10 timelmess by which blocks may be transferred across the data network turns on the 
available network throughput and characteristics, a separate load map 24 may be 
generated for each network environment enq)loyed by users. Thus, if experience 
shows ^hat users employ network connections providing one of three througIq)uts arid 
characteistics, 3Mbit or greater with QOS, 1Mbit with high latency or 30GKbit with 

15 low latency, each titie can have tibree sepaiate load maps, each providing a schedule 
and method of access suited for a respective biae 

More specifically, the load maps 24 may describe the content access pattdbas 
of the tities 22, parameterized typically by time, by access history and by runtime 
state of tifle. Additionally load maps may contain the access methods to be deployed 

20 by for a given access pattern and runtime title state. The load mq>s 24 cooperate wifli 
associated loafl map readers 52, to provide veUcles for dis^ 
title behavior and state, in tenns of accessing bto^ 

The load maps 24 contain data and the load maj) readers 52 contain executable code 

to interpret the infonriatidn of the load maps. The load map readers 52, monitoruig the ■ 

25 running tities brig network utilization, and operating on the data in the load ms^ 24, 
perform the client cache transactions for sustaining the title experience when client 
bandvwdth is limited. Typically, tiie process tiie load map readers 52 employ are . 
developed by obsendng and analyzing the behavior of a class of titles arid developing 
algorithm and access methods that best si5)port the class of behaviors. For individual 

30 tities data fliat defines titie behavior is then collected from a number of titie rims by 
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the profiler 28, and aggregated and encoded into load maps 24 for tiie title that 
corresponds to the map reader and network conditions Additionally data that dejSnes 
tide behavior can also be collected fiom the cache manager 40 as tifles are run my 
remote users. 

5 L^ad maps in the embodiment 6f Figure 

One such load m^ container 80 is depict^ in Figur^ 2. Each load m^ container 80 
is associated with one briq. A loiad in^ cbntaio^ 80 contains one or more loiad nii^s 
82. Each title ia the briq 22 is aissodat^ w 
wnfedner 80, Each load m^ 82 in^^ 
10 Descriptor 84. - 

In one practice, when choosing a load indp 82 for a titie session, the client 14 
locates the load map cpntaino: 80 for the tide's M 

directory within the load map contamer 80, and selects the load map 82 within tiiis 
directory >?Aich is associated with die Network Metric Descriptor 84 closest to the 

15 netwotk environment in which tiie tide session is to take place. Typically, the client 
14 cbrn^ares th^ aviilaibie^i^ 
withm the Netwoik Metric Dwi^ 
comparisonu 

Each loa4 inap 82 may TOiif^ 

20 iricMei^t fields TOthin the c^^ 

infoi3nation90| and predictive loa^ ' 
iiiforinatibn 88 can (comprise infonnatibn is used by tiie client 14 when storing 
iQ<X)imng datainthe cUenf s c^ ■ 

25 list or soioie other suitable algorithm for detdimning \^tet information to keep in the 
cache. The infbrmation can also include amount bf cache space to be allocated 
exclusively for the titie; and the relative caching prioriiy of each briq block, used by 
the cache replacement dgorithm whe^ 
into the cache. 
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The preload infonridoa^i^^ 
present in the cKenfs cadie before the tifle's executable is launched. TypicaUy. the 
6sta'thenetworic1hrouglqnit,1hesniaUer1hentm^^ 

preloaded into cache prior to fte title storting execution In either case, those blocks 
that need tp be preloaded may be stored in fte field 90 as an ordered list. 

The load in^ 82 may optionaUy contain predictive loading information in 
fifeld92. This information n% be uaxlh^tiieload^^m^^^^^ 
conhajt vAile fte title is nimun& even thotigh the title 48 has not yet accessed them. 
This hrfoimation may include one oir ino^ 

An ordered list of briq blocks to be fetched, without considering the progress 
of aparticular title session. The client 14 is to fetch blocks on this list, m the given 
order, during periods when the running title's netwo^ TMs list is 

known as a posdoad list 

Alternatiydy,tfaefidd92riiayc<)ntriina tree striicture of sets of bnq blocks. 
15 each set potentially assodated wife multo 
cUentdetectstibrttbfibkktohriMfc 
Wocksmthesewidsetaitetobe^l^^ 

Icnowa as the Probabilistic loading list, and this is ^ 
2. Ite data structures associated with ti^^ 
20 slructureofsetsofdate.Eadiofth^setsctint^^ 
definition: A s6t of triggering events that wodd cato^ 

ftern^nadertocontinnewhhitsiftobabil^^ Tiie cache manager 40 

'25 .belbadedneid."''. . 

. TaiigetsefcAhoideiirflistdfbld^^^^^^ 
by tiie title m the nea^ fixture. 

Probabmty of conectness: Tie prbbabiUly that, if the event is detected, the 
faiget set of blocks M^uldbcKiqimed ' ; 

consid^aiiig a plinaUtjr of events and choosing betwe^ 
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Longevity of prediction: the span of title activity (quantified in title briq 
accesses and/or in wall clock time), which the prediction claims to cover. After this 
span is exhausted (the title has peifom 
h^ passed, since the putative event), tiie piedicdo 
5 ignored. 

liius, the load map 24 contiaiiis in^^ 
employ for downloadu% blocks fi-bm the brig in a manner that mamtainR th>>. (fft.qirftd 
user experience. 

, Turmng now to Figure i/one exami)le of how a loa^ 
10 employed for deUvaing content more efficiently ova: a network is depict 
SpecificaUy, Figure 3 dq)icts the load demand for a title over a period of time 
Also dq>icted in Figure 3 is the available bandwidth. The available bandwidth is 
rioted by the horizontal line BW, and for the dep^ 

As can b^ seen during the time period T, the l6ad demand for the title sometimes rises 
15 above the available bandwidth. These peak tuhes: are shown to as having dashed lines 
ekteridmg throU^ the peab 

bandwidth available exceeds the baridwidithj^ For 
. ihstahcie, this may occur because the running title has loaded all the blocks it needs to 
si5)port a task that typicaUy requires the user to spend a meau^^ 
20 pdfonriing the tasL To address this issue the load map 24 inay be employed to 

schedule delivery ofblocks of the title duriDig tiiose times ofexcess bandwidth, and to 
employ those times to deliver data into a cache on the client This is shown in Figure 

; n 

to b€j needed in the fiitttre. Thy 
• 25 by the e5xecirtingtitie,vw&out requiring 

The activity of the map reader to requ^ data to be delivered over the network 
during times of excess capacity turris in part on the m 
■ ; ; * : niap. In particular, the load map^i^ , 

sets out an outline for possible file access patterns for the title given certain operating 
30 conditions. The decision tree loay be employed by the m^ reader to generate <^ 
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requests to flie RAFT server. By predictivdy caching portions ofthe executable, the 
system im)vides better ied4mie perfbimance for liw 

Hie Profiler 28 component is the primary piece of the title preparation 
process: it observes the execution of a title 30 ah^ 
5 based on andysisofihe title's disk acoKs patterns and selects 

cbaracteristics. The process employed by the profiler 28 can depend upon the 
apphca&on. Typically, the profiler 28 monitors the access patterns of a title as auser 
employs flie title. Additionally flie profiler can receive and use titie access patterns 
fiom remote users tiiat accessing a deployed system. The profiler 28 can build a log 
10 of tiiese access. Given some useful patteiiis, possible profilmg and m^ reading 
algorifliins can be tested and validated by simulation. Then tiie appropriate 
components can be devdoped to support eadi map type. 

Note tiiat'flie ardutecture of Figure 1 depicts load maps 24 as distinct from 
thetiflehiiqs22forreas6nsofbotiidarityandeffic^^ . 
15 «aiq)arativelysmaUaDd are likely to be 
coikettt Load ra^ will need a veraohl^ 

server 20 data synctaoniaation is not a problem. Logistical (distribution) issues could 
force load m^ to become physicaUy part of a briq, but such as change is witiim tiie 
skill of tiie ordinary artisian.. 
20 the load in^ forniat an^^ 

appfic^on, and based on fectors such as tWe, action \nthin^ ti 

of OTitime e3q)erience (fieezes), and statistical analysis may be employed to 

; of title delivery bandwidth 

^ MB teRi^ sfeiVer 20 j^flie^^^^ 14. Each should track 

bandwidth add be qUeryable by the Dispatcher or Playei/store front so float tiie 
cdstomerCahbe |jreseiited wi& appropriate choices and estimates of deUvery time. 

In addition to tiie Dispatcher 18 , it may also be desirable to have a daemon 
PWK^ tiiat resides on tiie CUent 
30 : ^abiHty when tiie cache Manager 40 is i^^^ 
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Stay iq>-to-date with network conditions and be qtieiyiable directly by the server fiont 
end 16. 
The Client 

As shown m Fig. 1, the depicted client 14 includes a web browser 32 having 
5 plug in 34 , a player 38, a cabhe manager 40, a plurality of title caches 42 a, b and c 
respectively, and a cache admin tool. As further shown tiie client 14 includes a 
runninig title 48, a plurality of m^ readas 52 a, b and c respectively and a plurality 
of cached title load maps 54 a, b and c respectively. Althbu^ only one server 12 and 
one clieiit 1 4 are dq)icted in Figure 1 , it will be undrastood that the systems arid 
10 methods described hraein include systemiis and methods where multiple servers 12 are 
employed arid v^ere each server may sxxpport ia plurality of client 14. For example, 
depending upon the applicatioii, the server 12 may support a thousand client systems 
14. 

The web browser may be any statable web brbwsers, and typically comprises 
15 ari HTML browser such as NetScq)e Navigator or M For the 

depicted embodiment, the browser is provided a plug-in The Plug in allows the server 
fiont end 16 to communicate wifli the player: and to cauise actions on the player side 
and to gather data such as version numbers, throughput measurements, and other 
irrformiation However, the type of browser employed w^ 
20 application, and in those applications where the device is unable to support a typical 
browser, a proprietary cUent application may be provided for exchanging data with 
the server 12. ? 

the jilayex 38 depicted MFigufe^^^^V Windovvs 
appUcation cbn^iniii^ 

25 and ithe CAS 68. Thb player 38 riiay be invoked by the client's browiser 32, and may 
include a library vrfiich may be implement^ as a siaries of objects or program code 
which generate and receive communications to/from tiiie CAS server 68 through ^ 
remote procedure call (RFC) library, the playear 38 may also include a process for 
moving data across the nejtwork and for measuring available network resources arid 

30 characteristicis including throu^put, bandwidth, lat^cy,buff^ 
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parameters. AdditidiiaUy. the player is capable of processing i^^^ 
the server 12 to determine for a tide of int^^ 
available loadmj^s for that title should be employed. 

Uponiiivocationofplayer38.agiapUc«serinterfece(GU5 
iiser. In flie illustrative embodiiiient. the user inteifece includes the appropriate 
Irtogramlogicand/orobjectsnecessaQrt^ 
aH»Kcati6ni«ogram(APIs)containedvdlhinthe^^^^ 
or«iviiomnenteinorderto:Tender>vindo>vs.p^^^ 

windo^vs. and receive conmiands W auserviaakeyboard, mouse w 
devices, such user inferfece being weU ^ihin the scope of those reasonably skilled in 
the art-Through this GUI. the user may set user preferences, e.g.. disk cache size, and 
benotifiedof error conditions. The player 38 cm launch a title and continue 
coiamunications between Ihe client 14 and the CAS 68 and the RAFT server 20. 

The depicted PI^ 38 is also an mtranediaiy between the CAS and the cache 
manger. In the ptoeess of running a tide, the player 38 locates the BSFs Dispatcher 
service 1 8 and queries it for mfomiation abbitt a suitable 
managd- 40 which RAFT coniiection to inake; provides fl» RAFT title or content 
accesskq«fiomtheCAStothecad.emanager40.andreft^ 
68 as needed, configures the approimate map reader 52a,b.c w^^ 

information, such as bandwidth and dei^ inode information; and sta^ 
aji>plication as needed. 

The playei-s 3 8 interaction with tiie Dispateher 1 8 may optionally m^^^ 
: b^dd. test A^theiii^38 (atflai^ tooj ^ „^ j,^ : 

^.si^i^forced to do s6 l^ti«ie^^ contend or by user's choice;. 

m.d^ctisdcachemanageri^ 
Eadi<^may be associated withaqx^^ 
«qxjndstorequests&m&eplay*38,^dicon^ 
RAFT server 20. hriq 22, andloadmj* 24. Ihecachem^ 
to tiie map iead« 52a.b,c, which mak^ antidpatory load requests fl^ 
Ae tifle's load map 54a,b,c and cunent execution state. 
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Tfe cache manager 40 provides a block direcil^ 
available, miakes a request of the RAFT sen^ 

local copy of yet The algorithmby which the cache is managed can be simple LRU 

optionally, may also encode aiod use load map infoimatiOn that preserves critical 
5 cache data wMchioaay not be accessed 

^ detiamine substantially optimum ciache size for eiach title, and possibly for each 

bandwidth tier m vrfiich title may execute^ 

The cache manager 40 also records the load state of the cac 

that it knows which blocks aire in cachb. This infoiniation allows the inap reader 
1 0 request that are not in cache to access the contoit server 20 and allows the pi ay er 3 8 

to determine whether the title shotdd be allowed to nm or not 

The cache admin tool 44 provides a GUI vAdoh allows administration of local 

caches by the eiid user, ft shows how mudi disk q>ace is taken up by each tifle and 

aUbws;flietiS!CTtodiq)oseofca^ The 
15. usbr caih stM this too 

recoiitiguiMoii of cache^ 

As <fiscussed above, the depicted map re£^ 

genctoied, title-ispecific load map 54a,b,c that has been downloaded from the server 

12 to &e client 14. As shown in Figure 1, for a gi^ 
20 inap 54a,b,c is present for each title 48. The load map 54a,b,c describes the content 

access patterns of the tifle appUcation, parameterized 

As discussed with reference to Fig^ 

■ • 5 -^^^ 

: - ■ : • . ; . 25 : ivaiiaWe a^^dn asp^^ To do this, tibe 

ihai) readeir 52a,b,c uses the prdffl 
. time delta which will be vmable during executioa 

The Map ReadCT API and one or more iUij^^ 
reiuiers may become a part of a ti^^ 
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Accoidingjy, Figure 1 dqrittoabliock^^ 
eiemerits of one embodiment of the invention, which anbodiment comprises a system 

fordeUveringcontentoveradatanet^irorictosupportexecutionofaprog^ 
lemotB location* in the igrstem 10 of Fignre^^^^ 

5 cooperatetodeUverportionsofekecuta>Iecode6v»^^^ 
to aUo^ra a us« operating the cUent PC^ 

program on the remote device in a manner that provides for tii^ same, or substantiaUy 

mie, user wperience that the tiser woU^^^ 

proghaifliatwasstoredlocanyfflida^^ 
10 applying flie cUent server ardutecture of Figmfc 1. tiie systeitt 10 is capable of 

providing a server system that any diettt can acoa^ for the purpose of downloading a 

program, or title, tiiat the user is interested in naming. For tiiis pa^ 

embodiment, the server 12 includes a fiont^ 60 that comprises a web stbrefiont 62, 

m e-commeix» server M and a conditioual accse& 
15 Aerefoteprovidesandectrohicstorefro^^ 

vsexto fWRto access to a tifle st6r^ bi' oiQie^ acceSable to, tiie server 12. 

Optaatioh o f tiie Depicted System 10 

In tite depicted embodiinent, usere^ 

storefent provided by flie storefront systto 
20 available tities. Upon selection of the tide, tiie usk negotiates for ah actual purchase 

of tiie titie. Negotikon m^ inchide tteer registraioli wifli a tiiird party, electronic 

conmiercesyrt 

purditeet^^ : ; 

^5 %asiiigfe^^^ 

time pinod e.g,, week; montii. ete/ ^ ^ ^ 

Forthe dq>icted embodiment, tiie sdv^ 12 mcludes tiie ftont-end 60that 
provide tiie aboveKiescnT)ed ded^ 

;tiiose:ofordinaryddnintiieartto : 
of fiont-end iiavigational server dq>eiids ontiie t^Hcation athand and an ahemative 

• • ■■ ■ -21- • ' . ■ . . ■ . ■ ■ 
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emboiJiment, tihie navigatioiM server miay be removed from the sfystems and methods 
described herein. Additionally, the particular embodiment of Figure 1 shovvs the 
front-end server 60 as including a transactioiial e^inmerce server 64. It will be , 
understood that flie transactional e-cominerce s^er 64 may comprise a server system 
integrated into the Server 12, or, in alternate embodiments, may be siq)ported by a 
third-party service prouder such that the e-conunerce server 64 may be located at a 
remote location and not integrated into the front-end 60. Oibsr elements shown in the 
front-end 60 including the web storefront, may also, in whole or in part, be supplied 
or siq)ported by third-party systOTS tfaiat are accessed, but reinbte from, the front-end 
60. • 

However, continuing wifli the example syst^ of Figure 1, the user would 
negotiate a transaction to receive access to tiie title of interest Upon completion of 
the purchase negotiation, tiien client software running on the user's PC obtains an 
authorization token and keying material frx)m the Conditional Access Server (CAS) 
68. The token authorizes the client 14 to rim the selected title from the file server 12 
across the network, the data retrieved from the file server 12 is encrypted. The client 
14 uses die keying material provided by the CAS 68 to decrypt the data from the file 
server 12. In one specific example, the eCommerce server 64 generates a launch 
string, containing the information identifying and authori2ing the purchase, including 
a Universal Resource Name (URN) uniquely idehtijfyiQg the desired title. The launch 
string inay be digitally signed by tiie CAS 68 and provided to the eCommerce server 
64 for deli very to the client 1 4. 

The launch istring, in 6ne:pta;ctice is l?VTapi)ed with a MlME header. When the 
lauribh string is receiv^ by t^^ 

the launch stririg is located in a registcy entry, which results in the invocation of a 
player module 38 within the client 14. The player module 38 establishes a secure RPC 
coniiectioh with the CAS 68 and requests that CAS provide a URL for the specified 

conesponding title data. The CAS 68 forwards tiie correq)onding URL to the player 
38. Once the player 38 has identified the location bif the corresponding data, the player 
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38 sends aptiichase request to tbe CAS 68, the purchase request including the Laundi 
string. 

Wilii to ^bodiinent, tWes nm on the 
downloaded, in its entirety, onto the PC. A title is fonnalted into an electronic 
package that contains the title's fOes in a compressed and enci^ 
as a briq. The feiq is aportable, self-contained file system, containing the data to 
makes up the files to be employed to run a particular title. Briqs are stored on the file 
server 12, Of a storage device or system accessible by the server 12 or to which the 
server 12 can lefeflw client 14. lie servwthirt manages the tifles is referred to . 
heteafler as the RAFT server 20. ITie cUent 1 4 treats flie briq like a local file system 
ontheuser's computer. When nmmng a title, the operatmg system, e.g. Windows, 

makes read requests to this local file system. The cUem 14, wMch, in fte iUustrati 
embo(fiment, mdudes a cadie manager 40, serwces these requests by 
requestedblocbofhriqdatefiomlheRAFTserver20.Afl^ 
block of data, cadiemanager 40 decompresses and deraypts the briq data, andpasses 
the data ohto the opera^mgsystem on the user's com 

Tuning, to Figure 1, one exan^ite of snckahopoationca^^^ ' 
Spedficdly.fiwflies:^ 10 of Figure 1 flieCAS 68 verifies the launch string's 
signature, and then letmns a RAFT aafliorizatiori token and activator to the player 38. 
The auflMMizatidn tokeb m^ be actually embedded wiflun the activator. Next, the 
plajra: 38 laiiiKAes the title b^ 

^ Tiie cache inmiaga 40 s^ l§ervCT20; 
1^ 

25 flftnager4diiSesftea<«vato • 

hriq data, and perfonn mt^fy checking on the blocks of de^ 
The^^ 

presented by cadiernanagft.Periodicdly.ft^ 

the dAS 6$ tb refieshflie activator aiidlhe RAFT aMiorization token. Upon the first 
of such requests, fte GAS 68 posts the pmxAase to the eCommerce server 64 for 
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tr^action settlement the ilfetime of the fiist^ctivator may be on the orier of 
minutes. Successful activator refiesh after the first timeout serves as an inidication that 
the title is running successfully on the client 14. 

Tlius, in this embodiment the software tifle is never ^ 
5 14. The client 14 creates an installation ahfrtractlftn^ mflintflinwg th** illusion for the 
operating sfystem that the title cuitently executing is installed on the host computer. 
Thus, v^en execution of the title is terminate(^ there is no remaining evidence the 
title rah on the system. No files associated with th6 title are left on the computer's 
haird-drive, and no operating sys^th ^tate iiiforr&ation e.gi^ regist^ 

10 associated witii the titie, retoains. Optionally, iiiseis of titles have tiie option of saving 
certain, state information that would be desnable to niiaintain aax>ss plays; e.g., the 
'lever achieved m a game, etc. Such stite information miay be saved m write through 
file described hereinafter. 

Optionally, the client 14 uses tiie Random Access File Traiisport (RAFT) 

15 protocol to retrieve briq data across the network. Tte protocol, in one practice, nmy 
provide the client 14 with read-only acCeiss to files and dnectories stored on RAFT 
server 20. Because the briq is treated like a Ibcal file system^ tiie RAFT client does not 
need to be visible as an dpeiating system drive and does not need to interface with the 
operating systerh^s fille System manager, tiie Windows installable File System (DPS) 

20 litenageir in flie illustrative embodiment As a result, the RAFT client file system - 
driver, flie cache manager 40 in the illustrative embodiment, is smalls and simpler 
than a remote or network file systein drivCT. Optionally, the RAFT protocol si5)ports 
; dyntoiic bahd\w^ 

. tiik>iighthE^iis;edf ^ ■ ? ;^ ly: 

25 thecUent M may employ avanety^ o^^^^^^ 

fiom uimuthori2«d access and replay. Authorization tokeris and dec^ 
obtained from a CAS 68. Network communication between the client 14 aui CAS 68 
rhay be protected via a secure remote pmcfedure call (RFC) interfece. Once a swiiire 
channel is established between client 14 and GAS 68, the client 14 requests a RAFT. 

30 authorization token and keymg material for th6 selectwi titie. The airthoriiatioii token, 
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in dhe embddiixient rxisy be a sigaed niessage fi6hi:i^ GAS 68 iiidicatirig iSaat the 
iequestmg user can have access to a specified btiq^ dh a specific RAFT file server 20, 
for &e length of thne speUed oiit m the neg^^ 

While the RAFT authorization token gives a cli^t 14 access to a tifle'is briq^ flib clieid; 

5 14 in certain embodiments, is to unpack, e.g. decompress and decrypt, the briq to gain 
access to the title's file data. The CAS 68 provides the user with the keyuig noiatetial 
to decrypt briq data. In one practice, the GAS 68 does not dkectly provide the client 
14 with keying material, histead, tiie CAS 68 may hide k^g inatdcial fixnii the user 
by embedding the keys m ob&scated bylecode that implements the decryption 

10 algorithm. Rather than deliverii^ isolated keying material to flie client 14, the CAS 68 
delivers obfuscated bytecode, referred to as an activator. The client's cache manager 
40 decrypts briq data by running the activator on a bytecode interpreter. Optionally, 
both the RAFT authentication tokens and activators may have a Um^ 
eixample, in certain embodiments, authorization tokens include an expiration time, 

15 after which they are no longer valid. Similarly, a ninhing activator, at a certain point, 
may initiate an exchange with the CAS 68 to rej&esh itself. If the exchange is 
unsuccessful, the activator beconi^ inoperable arid the titie inoperable. The refreshing 
of activators is referred to as activator keep alive. 

It will be understood that the system depicted in Figure 1 maybe supported by 

20 or implemented on conventional data pro<^ For example, the client 

systeixis can be any suitable computer system such as a jPC workstation, a handheld 
computing device, a wireless conlmunication deyice, or any other such device, 
equipjped with ia network client capable of aCcesisirig a network server and interacting 
with tiie server to exch^ge information with the server. In one embodimentj the 

25 network client is a web client, such as a web browser that can include the Netisc;^ 
web browser, the Microsoft Internet ejqpldrer web br^ 
. a proprietary web browser, or web client that allows the user to exchange data with a 
w^b server, and ftp server, a gopher server^ or sbnie other type of network server; 
The servers may be supported by a cdiiiimiercially available server platform 

30 sudiasaSimSparc™systemandranningas^ 
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exctianging data ^dth, one of the subscriber systems. Jn the embodiment of Figure 1, 
the server includes aprograiii for delivering content over a TCP/IP data network. 
Such programs may be vvritten using princ^ 




5 functional block elements. Howevei:; it Will be apparent to one of ordinary skill in 
the art that thesb elements cim b6 reaUzed as donq)uter programs or portions of 
coiiq[>ut6r programs thi^^ 

thereby configure thb data ^roces^bir a systc^ acbording to the inventioiL The 
elements/ such ds the plaiyer and profiler can realized as a software component 

10 operating on a conveiitionai data procesising system such as a Unix or Windows 
workstation. In that embodiment, these mechanisms can be implemented iis a C 
. language computer program, or a cbinputer program written in any high level 
language including C+ +, Fortran^ Java or basic. General techniques for high level 
prbjgramriiing are k^ Kochan 

15 ProgriimruhgM^Q^ 
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1. * Ame&od of tiansimtdhgiUita 
program at a remote location coi^^ 
detenoiimng a mieasi^ 
5 identifying Moiniati 

looking load map of icfotmatio^^^ 

based on ffae load isiap and die executioxi state, gen^iating ah antidpatoiy load request 
for transmitting the information within Hie available tirroujghput and for inaintaining 
cohsist^texeciitionofthepro - 
10 2. The meflidd of claim IjWhiErah the ^i^^ 
or an executable file. 

3. The method of claim 1, vdiereiri the infoitnation is transmitted fix>m a server to 
•'aclient ; 

4. Themeffiodofcl^ 

15 infbnnation based on the availsd^le tlnotiih;^^^ execution state of the program 
at a tiine of selection. 

5. The inethdd of claim 3, further icoflipris 
the cUe^ rekpiesting infoni^ 

the client selecting a subset 6f th6 mfoin^ based on the available 
20 throughput at a time of selbctionj i^^ 
the cUent selecting, for trans^ 
firom the subset of the information. 

6. The method ofclaim3, fi3r&er comprising: ; 
the client requesting information to be transimtt^^^ 

25 receiving a key adapted to access the information for transmission from the server to 
> the client 

7. Tie mefliod of claim l ,Svherein ti^^ 

based an access pattern for the trainsmitted infoimdtidiL 

8. A system for trmismittiiig stnictured ibfdirnation over a network having an 
3 0 identified available throughptit, c6in^ 
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a servd" ^ndviding the infom 
a cU^t receiving fhe iiiforizmtioiQ fiK)m&^ 
a profiler mdiDitoni^ transou^ 
generating at least one load map based oh an analysis of an information access pattern 
5 atthe server, 

a map reader, based on tbe at least one load msp^ for interpreting information 
(X)htaihed within a load map and for geheratm 
based on available throughput and infdi^^ 

a cache manager that merges the i4forbiati6n . to organize the structured 
10 informadon, for use by the client 

i 0. The system of claim 8^ the cache manager further including storage means to 
store at least the information associated with a preload operation, 

1 1. The system of claim 10, wherein the cache nianager selects for niefging a 
block of the inforaiation from the storagb meaii^,^tf^ 

15 requests a block froni the sierver, if the block is not yet available. 

12. The system ofdaim 8, further cwmprisiug a p 
execution of the structured information. 

13. A method for providing multiple levek of support for executing over a 
cbnipuler netwoik a progrim having blocks of executable code, con^rising 

20 providing, for a plurdity of network pCT^^ 

riiaps associated with respective ori6s of said netwoik performance levels and having a 
list of sections of exebutable code of ffie pibg^in 6ide^ according to the expected 
. ;X>ri(m1yof2b^^ 

•^leterih^^ 

•'25' -^cUeiai ; • V- ■ 
selecting a load niap as B fimctioh of 

■ and; . 

allowing the cli^t to ri^iiest sis(^ohs of thc^ prograni aiccording to the Ibad : 
map selected. 

30 14. A niethod aocdrdihjg' to claim 13^ fiirtfaier including 

-28- 
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processmg ^flie program 

15. A mdhojcl according to claim 14, vdierdnj^^^ 

determining for a respective network prafoimance level a preload list representative 
of a series of sections of executjible code lhait iare to be transmitted ovct the network 
5 prior to execution of tiie program, 

16. A method according to claim 14, wherein processing the program mcludes 
monitoring execution of the program to detemiine a sequence of block fetches for 
moving sections of exeicutable code into cdnipiEter nl^mory and cache during program 
exi^tion. 

10 17. A method accordmgto claim 14, \\iierein gOTerating 

ordering the list to provide a delivery sequence for scheduling delivery of sections of 
executable code over the network to the client 

18. Amethod according to claim 14j wherein processiiig the program includes 
generating the ordered list to schedule transmission of executable code over tte 

15 network during a period of low network activity during program execution. 

19. A rhethod according to claim 13, wherein determining a network performance 
level includes lalmching a player program at the cUent capable of exchan^ 
infomation with a remote server for determining the available network bandwidth. 

20. A method according to claim 13, wherein determiiring a network performance 
20 level includes laiihching a player program at the clieait capable of ex ch an g in g 

iMormation with a remote server for deteimining^^^n^ 

21. A method according to claim 13, wherein determining a network performaiice 
level includes deteimining ca<ie mraa 

22. A method according to claim 13, w^ 
25 . coinparing a network performance level^^^ 

of aloadmap as a ftmction of titie comparison. 

23. A mgthod ac<tf>T ding to c Mm W fiirtiher including 

^ sbiectihg one of aplurality of servers for transmitting information. 

24. A method for prbviding multiple levels of s^ 

30 computer network a program having blocks of ekecutable code, comprising 

J29- 
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. providing a file system ma^ 
operations of a computer program executing within aii implication niemoiy spacb, 

exiecuting the program, 

eniploymg the £U[e system manageineiit ^ 
executed, for determining a sequence and a timing pattern with which blocks of 
executable code are loaded mto thie application memory space, and 

processing the sequence aiid timing pktteiii to generate a load map 
representative of a sequence and timing pattern for transmitting blocks of executable 
code over the network. 

25. * A method according to claim 24, wherein processing the sequence and timing 
pattern includes gen^iating a plurality of load maps eaich associated with a respective 
level of network performance. 

26. A method according to claim 24, wherein executing the program includes 
executing the program a pluriality of times to identify a plurality of optional seqtieiice 
and timing patterns for loading blocks of the executable program into application 
memory space. 

27. A method according to claim 24^ viixisrem geo^^ the loadi map includes 
processmg the sequience and timing piattem to det^inine a preload factor 
representative of a number of blocks 6f exectitable code that are to be transmitted for 
enabling execution of the program over tiie netwoirk. 

28. A prociess according to claim 24, wherein generating a load map iricludes 
processing the sequence and timing pattern to idehtify periods during prograra 
execution available for triis^ additibiiaA blocks of execiito 

29. A proems according to claiin 28, inclu^ deteiMiiing prbbabiHstiCaUy thcj ' 
additionai blocks of executable code to^^^^^ 

30. A process accordiiig to claim 24, wherein processing the sequence arid timing 
pattern includes eoUectinig information repifeisentative of blocks of executable code 
requested fiom a remote site mi adjusting the Idaidmap as a fuhctibn of the collected 
informatiorL 

-30- 
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31, A process accoiding to claim 14, 

within the generated load map for contrdiling post-load execution on a client based on 
programs file accesses. 

32. A process according to cladm24j fi^ 

5 providing a m^ reader process for iebci^ 

load map to detenmne a sequence for reqiifesting blocks of exw code from a 
remote server. 
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